# 前言

通过前 2 章的内容，此时应该已经顺利的搭建了开发环境，也熟悉了服务器、shell 脚本的一些基本知识。

通常开发项目之前，一般都会有 Prd（项目需求文档），会详细介绍项目中的需求模块、功能设计等各种细节内容，避免开发中出现缺陷，后期迭代或拓展困难。

所以本章将会对整个项目进行需求分析与拆解，阅读本章你将会对工程化有进一步的了解，包括流程定制、Git Flew、权限设计、数据库建表等等。

# 项目分析

整个项目将分为 4 个学习模块，分别是：

• 服务端
• 客户端
• CI/CD
• 监控

# 大纲设计

1. 搭建一整套开发-测试-构建-部署的流程 --> 规范化流程
2. 研发流程中加入能效概念（研发时间-测试时间-总体交付时间-bug 率及修复时间），作为项目提效的一个参考标准（影响因素太多，仅供参考） --> 流程闭环质量
3. 合理的提测卡点，减少无效的提测，减轻测试负担 --> 简化交付成本
4. 提供线上监控，分析每个版本使用率，报错率 --> 项目质量
5. 提供快速回滚指定版本功能，确保新版本崩溃情况下能够快速恢复服务 --> 线上稳定性

# DevOps 设计

在小册大纲中，附图是一个较为完整的 DevOps 的项目架构设计，但作为一个实战的项目练习，个人独立完成所有的流程显然是比较困难。

下图是简单版本的流程架构，整个项目将依照下图的简版流程进行开发。

# 分析与拆解

根据流程图可以简单将 Node 模块分为 4 个部分

1. 用户模块
   • 项目注册用户
   • GitLab 授权第三方注册用户
2. 角色模块
   • 管理员
   • 测试
   • 开发
3. 项目管理
   • 项目（增删改查一套）
   • 打通 GitLab，通过 Open Api 关联项目并进行管理
   • 创建任务流，对整个项目进行追踪管理
   • CICD 项目构建部分
4. 线上监控（方案暂定）

后续将按照上述 4 个模块逐步开发，具体的细节部分会在每个模块开发中介绍。

GitLab 除了是一款优秀的代码仓库管理平台之外，本身也具备当一个小型项目管理系统的潜质，包含的项目、团队、权限、用户、issue 等等功能都已经非常完善。后续的工程将会非常依赖 GitLab，对 GitLab 提供的开放功能进行深度拓展，定制出合适的工程化体系。

# 流程设计

如上图所示，将上述的发布流程更进一步的细化可以分为下面 4 类：

1. 单项目发布流程（一个需求只需要一个工程完成）
2. 生产环境出问题，快速回滚功能
3. 集成项目发布流程（一个需求可能会有多个工程参与开发、发布）
4. Bug 修复发布流程（无需求，需要快速修复线上已知但不紧急 bug 的发布流程）

任务流的设计其实非常复杂，为了加快交付第一版，先将任务流固定为以上 4 类，可以减少开发量与难度，后期可以添加或者修改某个流程。

# Git Flow 流程

Git Flow 的核心是通过在项目的不同阶段对 branch 的不同操作包括但不限于 create、marge、rebase 等来实现一个完整的高效率的工作流程。在项目的质量把控、多人协作中有非常好的实践。

• Production 分支

就是常用的 Master 分支，这个分支包含最近发布到生产环境的代码，最近发布的 Release， 这个分支只能从其他分支合并，不能在这个分支直接修改。

• Develop 分支

这个分支是的主开发分支，包含所有要发布到下一个 Release 的代码，这个主要合并于其他分支，比如 Feature 分支。

• Feature 分支

这个分支主要是用来开发一个新的功能，一旦开发完成，合并回 Develop 分支，并进入下一个 Release。

• Release 分支

当需要发布一个新 Release 的时候，基于 Develop 分支创建一个 Release 分支，完成 Release 后，合并到 Master 和 Develop 分支。

• Hotfix 分支

当在 Production 发现新的 Bug 时候，需要创建一个 Hotfix 分支, 完成修复后，合并回 Master 和 Develop 分支，所以 Hotfix 的改动会进入下一个 Release。

整体的分支管理流程如下图所示

# 项目自建流程

Git Flow 的优点非常明显，但在实际操作中，不能避免很多流程会有人工介入，有些环节不能完全约束与加入，所以 在 Git Flow 的基础上再创建项目的自建流程，将 branch 与自建流程关联，可以对项目中的开发节点、发布节点、测试以及监控等流程与功能进行追踪。